Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

#6057 Improve startup time #7486

Merged
merged 11 commits into from
Mar 10, 2021
Merged

Conversation

Ali96kz
Copy link
Contributor

@Ali96kz Ali96kz commented Mar 4, 2021

#6057 Check string is number with regex instead of throwing exception. It will improve start time because when I have 3000+ entries it throws about ~170.000 NumberFormatException
Снимок экрана 2021-03-04 в 21 38 30

  • Change in CHANGELOG.md described in a way that is understandable for the average user (if applicable)
  • Tests created for changes (if applicable)
  • Manually tested changed features in running JabRef (always required)
  • Screenshots added in PR description (for UI changes)
  • Checked documentation: Is the information available and up to date? If not created an issue at https://github.com/JabRef/user-documentation/issues or, even better, submitted a pull request to the documentation repository.

@Siedlerchr
Copy link
Member

I like the idea, but please check the org.jabref.gui.util.comparator.NumericFieldComparatorTest

@tobiasdiez
Copy link
Member

Thanks, that's indeed a nice improvement. However, regex are also pretty expensive, so there is still room for improvement. For example, https://stackoverflow.com/questions/11875424/java-regular-expression-offers-any-performance-benefit discusses a neat way using character-wise checks. There are some issues with this approach e.g. with negative or decimal numbers, but that's not really something we care about in the main table, so we can ignore them.

Another huge improvement would be to not use the numeric comparator for all fields by default. For example, it doesn't make any sense to try comparing authors by converting them first to numbers. I think, only the year columns needs such a treatment...and custom columns for which we don't know the format #6349.

@Ali96kz
Copy link
Contributor Author

Ali96kz commented Mar 5, 2021

@tobiasdiez I changed the number validation mechanism. I don't know how to implement the second suggestion because there is no way to get data type from MainTableColumnModel, what about creating a separate task?

@Siedlerchr Siedlerchr added the status: ready-for-review Pull Requests that are ready to be reviewed by the maintainers label Mar 6, 2021
Copy link
Member

@tobiasdiez tobiasdiez left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the quick follow-up. Two minor remarks from my side.

Concerning the installation of the compartor in the main table, you have the field available at

this.fields = FieldFactory.parseOrFields(model.getQualifier());
.
Thus you could add a check at
this.setComparator(new NumericFieldComparator());
if the field is a UnknownField or if it is numeric:

Copy link
Member

@tobiasdiez tobiasdiez left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The checkstyle fails; apart from this is good to go from my side.

@Ali96kz
Copy link
Contributor Author

Ali96kz commented Mar 9, 2021

@k3KAW8Pnf7mkmdSMPHz27 Are you a second reviewer?

@k3KAW8Pnf7mkmdSMPHz27
Copy link
Member

@Ali96kz unless someone else is taking a look at it earlier, I should be able to review it in a couple of hours.

Copy link
Member

@k3KAW8Pnf7mkmdSMPHz27 k3KAW8Pnf7mkmdSMPHz27 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks good to me! There is only one change I truly require (line 51 in NumericFieldComparator) and the rest are perhaps nitpicking.
Other than that, good changes. I am looking forward to the performance improvement 😍

(Sorry about the slightly later than promised review, I were less familiar with OrFields than I expected)

} catch (NumberFormatException ignore) {
// do nothing
// If we arrive at this stage then both values are actually numeric !
return valInt1 - valInt2;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know this isn't your code, but I'd rather see valInt1.compareTo(valInt2) here (even if it should not overflow with reasonable values). I believe it will help with avoiding auto-(un)boxing as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It will break a test

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For compareTwoNumericInputs I'd go either with 1 or changing it along the lines of https://junit.org/junit5/docs/snapshot/user-guide/index.html#writing-tests-test-interfaces-and-default-methods
e.g.,

assertTrue(comparator.compare("4", "2") > 0);

Copy link
Member

@Siedlerchr Siedlerchr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for tackling this issue!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: ready-for-review Pull Requests that are ready to be reviewed by the maintainers
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants